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Abstract — Safe human exploration in space missions requires 
careful management of limited resources such as breathable 
air and stored electrical energy. Daily activities for astronauts 
must be carefully planned with respect to such resources, and 
usage must be monitored as activities proceed to ensure that 
they can be completed while maintaining safe resource mar- 
gins. Such planning and monitoring can be complex because 
they depend on models of resource usage, the activities being 
planned, and uncertainties. This paper describes a system - 
and the technology behind it - for energy management of the 
NASA-Johnson Space Center’s Multi-Mission Space Explo- 
ration Vehicles (SEV), that provides, in an onboard advisory 
mode, situational awareness to astronauts and real-time guid- 
ance to mission operators. This new capability was evaluated 
during this year’s Desert RATS (Research and Technology 
Studies) planetary exploration analog test in Arizona. This 
software aided ground operators and crew members in modi- 
fying the day’s activities based on the real-time execution of 
the plan and on energy data received from the rovers. 
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1. Introduction 

All space missions share a need to optimize the use of con- 
sumable resources such as fuel, oxygen, water, and stored 
energy because these all contribute significantly to the lim- 
ited mass budget that can be delivered to a remote destina- 
tion. However, because these resources are critical to the 
success and safety of the mission, they generally cannot be 
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completely consumed. Some safety margins have to be main- 
tained at all times, and all activities must be carefully planned 
to ensure that these safety margins are ensured. This paper 
describes a prototype system developed for NASA’s Multi- 
Mission Space Exploration Vehicle (SEV) that provides an 
onboard, real-time advisory capability for astronauts to help 
them manage energy stored in the vehicle’s batteries. 

The “control system” core of the advisory system was 
adapted from an earlier demonstration system developed us- 
ing the Mission Data System (MDS) framework [1] for the 
ATHLETE rover at the Jet Propulsion Laboratory (JPL). This 
system features a real-time core and includes state estima- 
tors and state variable projection models along with the goal 
planner and executive. The advisory system communicates 
with the SEV using a common robotic API, allowing it to use 
the existing telemetry data delivery infrastructure. Separate 
user interface applications allow operators to propose activity 
plans to the planner and view detailed execution status, and 
existing driver console displays are used to present key status 
information to the crew. 

The SEV’s navigation display software uses Google 
Earth™ as a presentation layer framework for displaying a 
geographical map view of the activity plan, which is specified 
in custom kml files. So, a translator that extracts the way- 
point and timing data from the kml file and converts those 
into position goals and temporal constraints in a goal net- 
work representation of the plan was developed. Thus, when 
a user proposes an activity, two types of goals are created; 
the kml file generates activity-related goals and temporal con- 
straints, and flight rules and safety constraints generate addi- 
tional ones. The set of goals is then scheduled by the planner, 
which verifies that all temporal and state constraints are satis- 
fied across the plan according to the projection models for all 
relevant states. When the plan “executes,” the activity goals 
are achieved directly by the astronauts driving the rover, but 
the control system observes driving data and continually eval- 
uates progress against the plan using its projection models. 
Because of this, the system reports both immediate constraint 
violations and violations that will occur in the future. Specif- 
ically, it can detect when the current energy consumption rate 
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Figure 1 . NASA- Johnson Space Center’s Space Exploration 
Vehicle 


is such that a margin constraint will eventually be violated. 

An evaluation of this new capability was performed during 
this year’s Desert RATS planetary exploration analog test in 
Arizona. Dual rover operations for a fourteen-day traverse 
were planned with the aid of this new tool. In the field, 
this software aided astronauts driving the rovers by providing 
energy projections, including projections of energy needed 
to perform contingency (rescue) procedures. It supported 
ground operators in modifying the day’s activities based on 
the real-time execution of the plan and on energy data re- 
ceived from the rovers. 

This operationally useful capability is an innovative use of a 
goal-oriented control framework that was originally intended 
for autonomous embedded robotic control systems. The Mis- 
sion Data System frameworks provide easily adapted inter- 
faces for modeling the target system, its constraints and activ- 
ities, and integrated capabilities to further automate human- 
in-the-loop plan creation and repair. 

2. SEV and Desert RATS Overview 

NASA’s Multi-Mission Space Exploration Vehicle, shown in 
Figure 1, is a next-generation modular concept vehicle in- 
tended to be used in a variety of target environments includ- 
ing the moon, Mars, or even an asteroid [2]. The current gen- 
eration consists of an enclosed cabin mounted on a wheeled 
chassis. The cabin is designed to allow two crew members 
to live and work in shirt sleeves for up to two weeks; two 
spacesuit ports enable the crew to easily exit the cabin for 
extra- vehicular activity (EVA). The chassis features a crab 
design, allowing movement in any direction including 360 
degree point turns. Each SEV is powered by lithium-ion bat- 
teries with a specific energy of 125 W-hr/kg [2]. The require- 
ments for a flight version of the SEV call for batteries with a 
specific energy of 200 W-hr/kg. 

The SEV has been an integral part of the Desert RATS space 
surface operations analog test for the past three years. The 


2010 Desert RATS test had several objectives that pertained 
to the operation of two SEVs, each with two crew members. 
The crew spent seven days and nights in the rovers and cov- 
ered nearly 20 km per day. Several different methods of oper- 
ation were compared, including continuous communication 
versus twice-a-day communication with the mission control 
center, as well as leader-follower traversing versus a divide- 
and-conquer method [3]. 

One of the important operations concerns with the different 
traverse styles was contingency planning. It would be impor- 
tant on a real mission to consider rescue scenarios if one of 
the rovers became disabled. These rescue scenarios, or con- 
tingency plans, drive the implementation of flight rules for the 
analog test. These flight rules basically constrain the rovers 
to have enough power to rescue the other rover given two dif- 
ferent rescue scenarios at all times. In order to implement this 
type of control, a consumables model would be necessary, as 
well as detailed plans for both rovers. Given the twice-a-day 
communication paradigm, this knowledge must be automati- 
cally calculated so that it is available to the crew at any given 
time during their traverse. 

During the Desert RATS test, the system that will be de- 
scribed here calculated the appropriate contingency times, 
which were the times to complete the two contingency paths, 
including the necessary battery charge time and crew and sup- 
ply transfer times; the drive time, which was the maximum 
time that the rover could drive given the most constraining 
consumable; and the hold-and-wait time, which was the max- 
imum time the crew could survive in the stationary rover with 
only the essential systems powered, given the most constrain- 
ing consumable. 

3. System Design 

Requirements and Constraints 

Space operations must be designed to optimize the use of var- 
ious resources including fuel, oxygen, and stored energy. The 
cost and risk of getting those resources into space, along with 
the tanks, batteries, and other storage systems needed to sup- 
port them, are among the primary obstacles to human space 
exploration. Efficient use of resources implies a need to op- 
erate close to safety margins. Doing that safely when the 
resource usage is dynamic requires careful management of 
the resources. Operations must be planned in advance to fit 
within resource budgets, and then executed according to the 
plan. 

Due to the complex and interconnected nature of the missions 
and the resources, mission planning is not an open-loop pro- 
cess. Operational flexibility is needed to accommodate ex- 
ploration, uncertain environments, and the possibility of fail- 
ures. Models of resource usage must be a function of the plan, 
and these models must be updated as the plan changes so that 
safety constraints can be monitored in real-time. Because the 
production and consumption cycles are complex, no model 
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will account for everything, but it is critical that the resource 
is not exhausted during operations. So, constant reprojection 
of the models over the updated plan is imperative to ensure 
safety constraints will always be enforced. 

When designing this system for the SEV, consideration was 
given to where it would be most useful. Traditionally, this 
sort of oversight is performed in mission control (on earth). 
For the system to maintain precise knowledge of resource 
consumption requires mostly continuous access to measure- 
ments of consumption and production rates. The anticipated 
lunar surface operations near the poles could make commu- 
nications with the ground intermittent. In the field test envi- 
ronment, communications are even worse. So for the system 
to be able to continually monitor dynamic resource use and 
provide the earliest possible warning to astronauts requires 
that the system run onboard. In this demonstration project 
the system ran on a computer in the SEV’s chassis. 

Goal-Oriented Control and the Mission Data System 

The Mission Data System (MDS) [1] was designed as a 
general-purpose framework for robust control systems with 
this type of problem in mind. MDS provides a framework 
for modeling activity plans as constraint networks, and has a 
planning and execution engine that can verify constraint sat- 
isfaction at plan time and at run time through a process of 
automated real time state projection. 

In this system MDS was used in an advisory mode where the 
astronauts exercise control external to the software system. 
This “control system” is merely monitoring execution of the 
plan in order to enforce safety constraints. As described in 
[4], it makes sense to view this as a control system where the 
system models the astronauts as smart actuators. Its recom- 
mendations are interpreted by the astronauts as advice, but 
modeled in the system as commands [5]. 

System Energy Model 

Figure 2 depicts a simplified model of system states rele- 
vant to the battery energy state. To simplify the analysis 
and implementation only a few key producers and consumers 
of electrical power were included individually in this model. 
Ovals identify the system state variables of interest, and ar- 
rows indicate state effects (e.g., power consumption affects 
the battery state of charge). The triangles indicate measure- 
ments the system could produce as evidence for estimating 
states. 

Four major power consumers were considered in addition to 
the solar panels (simulated by outboard generators), which 
are the only energy producer. The largest consumer of power 
is the mobility system that includes the driving motors. Since 
these motors consume energy roughly as a function of dis- 
tance driven, and a separate onboard navigation system was 
able to provide position and velocity, this aggregation simpli- 
fied the analysis while providing reasonably good precision. 



Figure 2. Energy state effects diagram 


The active suspension motors were modeled as a separate 
group so that the model could reflect the policy to power the 
suspension only while driving, and turn it off when parked. 
All of the avionics and life support subsystems (called hotel 
loads) were modeled in two groups: one that is considered es- 
sential, and thus always present, and a second optional group 
that could be powered off to save energy in an emergency. 
This latter group enabled the system to consider discrete al- 
ternate optimal and sub-optimal tactics. 

The dashed lines in the figure indicate policy-based state ef- 
fects. The model enforces a flight rule that the simulated so- 
lar panels must be stowed while driving (and generating no 
energy), and an operational rule that says they will always 
be deployed when parked. A similar rule is enforced for the 
suspension. Such procedural effects create uncertainty in the 
projection models because the system cannot predict the pre- 
cise timing of astronauts following these procedures. 

Although mobility energy is roughly consumed as a function 
of distance driven, the condition of the surface (hard or soft, 
or size of rocks) will also have a significant effect. Similarly, 
the surface slope (change in potential energy) will have a no- 
ticeable effect. These effects were omitted from the initial 
model to keep the work in scope, but will be included in fu- 
ture updates. 

Activity Plan Model 

Activities are planned using a visualization system based on 
Google Earth (Figure 3) which allows scientists and mission 
planners to select observation sites on map overlays and then 
select approximate driving paths from one site to the next. 
Prototype plans can then be verified using a ground-based 
planning system that uses the same models as the advisory 
system. 

The xml-based output of this process (a Google Earth KML 
file) is used as the operational plan description for onboard 
visualization and as an input to the advisory system. This 
format provides only the location of each waypoint and the 
duration allowed for making observations and other activities 
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Figure 3. Example traverse map in Google Earth 


at that location. 

Mapping Activities to Goals 

The advisory system ingests this data and elaborates each lo- 
cation into a position goal (be at the location for the given 
duration) along with a preceding driving goal to move to that 
location. Mobility power goals reflecting model expectations 
are elaborated as a function of whether the vehicle was to be 
parked or moving across each interval. Additional goals are 
elaborated for the remaining power states reflecting the poli- 
cies for operating each subsystem. For example, the solar 
panel goals reflect the policy that they will be stowed while 
driving and deployed while parked. 

Crew and Mission Operations User Interfaces 

The outputs of the MDS advisory system are organized for 
consumption by the crew and mission control as a page in the 
SEV’s drive display graphical user interface (GUI). A screen- 
shot of this GUI page is shown in Figure 4. The GUI is com- 
prised of four basic sections: the energy projection graph, 
replan options, contingency flight rule times, and the energy 
gauge. 

The Energy Projection graph shows the maximum and mini- 
mum projected battery energy values at each future time point 
in the active plan. The uncertainty in the energy model causes 
these lines to diverge over time. Also displayed on the graph 
is the minimum battery energy constraint, the value of which 
is given to the advisory system as a maintenance safety con- 
straint based on a flight rule. This graph is updated by the 
advisory system every ten seconds. 

The replan options section consists of the Execution Status 
in the upper right corner, the Messages box directly under 
that, and the Replan Options box under the Energy Projec- 
tion graph. As long as the actual and the minimum projected 
energy constraints stay above the flight rule minimum energy 
constraint, the execution status is nominal, there will be no 
messages, and the Replan Options box will not be populated, 
as shown in Figure 4. However, if an actual or projected 
failure is detected, the execution status will change to “Re- 
plan Necessary” (actual failure) or “Possible Replan Needed” 





Figure 4. Screenshot of the energy management GUI 


(projected failure). The Messages box then displays the point 
in the plan at which the failure has been detected, and the Re- 
plan Options will be populated given the energy discrepancy 
at the point of failure. Three different options are calculated; 
first, the distance by which travel should be reduced is calcu- 
lated given a model that assumes the SEV travels at a nom- 
inal speed of 1 km/hr. Second, the amount of recharge time 
that should be added and when it should be added is calcu- 
lated, and finally, the amount of time that the non-essential 
hotel load is removed to account for the energy discrepancy 
is displayed. These numbers are meant as a starting point for 
mission operators or crew members who will be creating a 
new plan to account for the energy difference. An example of 
a failed plan is shown in Figure 5. 

The contingency flight rule times can be found on the right 
side of the GUI. While the rest of the GUI is listening to 
an energy advisory system that takes in actual data from the 
rover, this section is different. Because of the reduced capac- 
ity of the batteries that are currently in the SEVs compared to 
the requirements for the flight version, this section of the GUI 
listens to a simulated energy advisory system that is running 
models for the flight version of the SEV. This simulated sys- 
tem takes in the same plan as the live rover data version, but 
uses different energy models for projection and simulation of 
the vehicle’s energy response. 

Accurate contingency path distances are a function of both 
rovers’ positions, paths, and the location of the battery charg- 
ing apparatus, which may be separated from the SEV. Be- 
cause the minimum distance path between the two SEVs may 
not be traversable, a safe contingency path involves back- 
tracking via known path to an intersection point and following 
the planned path of the disabled SEV until it is found. Be- 
cause of this, calculating contingency path distances is com- 
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Figure 5. Screenshot of the energy management GUI when 
the plan has failed 

plex and requires a model of the combined dual SEV system. 
Currently, the model handles each SEV and its path indepen- 
dently, so a simplified model of the contingency path lengths 
is used. The path lengths are estimated by adding a crew- 
entered starting distance to the distance accumulated during 
the day’s traverse. The buttons along the edges of the box al- 
low the crew to easily adjust the starting distance for the day 
if the test plan called for it. The flight rule times are updated 
only when the “Calculate” button is pushed to avoid having 
the times change while the crew is reporting them back to 
mission control or to the other SEV. Two sets of flight rule 
times are displayed; the first are the times for the SEV that the 
drive display controls, and the other set are estimated times 
for the other SEV, given its plan for the day and a model of 
its power characteristics. 

Finally, the energy gauge part of the GUI consists of two 
boxes along the bottom edge, the Energy Gauge and the En- 
ergy Stored boxes. The Energy Stored box simply displays 
the current estimate of the actual rover’s battery capacity, up- 
dated every ten seconds from the energy advisory system. 
The Energy Gauge consists of a resettable infinite filter relat- 
ing energy usage and distance traveled. One is able to invert 
the units of the Energy Gauge, based on preference. The en- 
ergy and distance data used to populate the Energy Gauge box 
is updated every ten seconds from the energy advisory sys- 
tem. Altogether, the four pieces of the energy management 
GUI serve to inform the crew and the mission operators what 
the energy state of the vehicle is and how to update the plan 
if that energy state may in the future violate any constraint. 

4. Results from Desert RATS 

The energy advisory system and accompanying GUI display 
influenced how the Desert RATS test was conducted, both 


from the crew and the operations perspective. First, the pro- 
jection capability of the energy advisory system was used dur- 
ing traverse planning before the field test. As plans were de- 
signed, they were scheduled in the energy advisory system 
in a simulation mode, and the resulting projection graph was 
examined for potential problems due to battery energy. As a 
result, the traverse plans were sufficiently conservative with 
respect to energy. 

In the field, the operations crew used the energy advisory sys- 
tem in several ways. First the advisory system’s energy esti- 
mate was corroborated with other energy models, including 
the battery management system’s state of charge measure- 
ment and the engineers’ intuition and experience with the bat- 
tery’s capacity based on voltage. This system became very 
important when it was realized that the new power convert- 
ers allowed the vehicle to charge much faster than expected. 
The operations crew then decided not to charge at every op- 
portunity as dictated in the flight rule, and used the energy 
projection graph on the energy management GUI to choose 
when to charge and when not to. This approach worked very 
well, as there were no schedule changes due to the battery’s 
state of charge. 

The crews in the vehicles, in addition to using the en- 
ergy management GUI for the contingency path times, often 
looked at the GUI for the energy stored and energy gauge 
data. Comments during the test indicated that these pieces of 
information, in addition to the energy projection graph, gave 
the crew more situational awareness; in the past, the SEV’s 
state of charge was essentially a black box to the crew. The 
crew also visited this GUI page in order to check their con- 
tingency path times to fulfill a flight rule that required them 
to communicate these numbers to either mission control or 
the other vehicle’s crew before each EVA or every two hours. 
The intent of this flight rule was not to cause the crew to per- 
form any contingency procedures or have the day’s traverse 
in any way affected by these numbers, but instead it was to 
make the crew and the mission operators aware of the need 
for these sorts of rules and procedures. It was for this rea- 
son that a model of the flight version of the SEV generated 
the contingency path numbers instead of the analog test SEV 
model. 

The energy advisory system worked very well for the Desert 
RATS field test. The software was flexible enough to handle 
the discrepancies and delays that crept into the schedule as it 
continued to put out energy estimates while keeping track of 
where the plan should be. This was useful, as one could see 
how these disturbances affected the projected energy usage 
given the day’s nominal plan. The only failure experienced 
with this system was due to the contingency path times’ de- 
pendence on the distance actually traveled, which was pulled 
from a position estimate calculated by another piece of soft- 
ware. This could be mitigated in the future by better under- 
standing the uncertainty in the position estimation within the 
advisory system. 
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5. Conclusion 

The energy advisory system described in this paper predicted 
expected energy usage in the system given models of the sys- 
tem and plans of operations. This energy advisory system 
was run on board the SEV and evaluated at the Desert RATS 
analog test. While this software was not critical to mission 
success, it allowed operators to relax safety margins (such as 
the flight rule that dictated charging at every stop) in a safe 
manner because of the more accurate energy models it em- 
ployed. This software also allowed the crew more situational 
awareness and visibility into energy management, which was 
something only the mission operations team had in the past. 

Using MDS as the underlying engine provided a clean and 
efficient way to model the resources and their affecting states 
as a function of the activity plan. Adapting the models was 
completed very quickly with most of the development effort 
going into calibrating and testing the models onboard, and 
tuning the user interfaces. 

Future work includes many upgrades to the current model to 
extend its usefulness for monitoring flight rules and safety 
constraints in upcoming analog testing. First, the model 
would be upgraded to include both SEVs and their plans. 
Communications between the SEVs could then be tracked 
and the maximum time between communications could be 
constrained, according to an existing flight rule. Next, the 
removable battery charging apparatus would be included in 
the model, as well as a sunlight model. This and the dual 
SEV model would allow for more accurate calculations of 
the contingency path distances and times. Simple models of 
other consumables, such as oxygen and water, would also be 
included to make the drive and hold-and-wait contingency 
times more correct. The terrain features like roughness and 
height could be included in the model to improve the pre- 
diction of mobility power usage, which is the greatest cause 
of uncertainty in the current model. Finally, the battery en- 
ergy storage model could be improved from the simple linear 
model currently used to give the energy projection more fi- 
delity. 
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